Thank you for the PR. I do not think this is a bug. This is expected because the internal meta is not useful to the caller and hence, we write the UserMeta into meta before publishing.

Thank you for the PR. I do not think this is a bug. This is expected because the internal meta is not useful to the caller and hence, we write the UserMeta into meta before publishing.

Why not write the UserMeta into UserMeta? as a caller of the Subscribe API, I was confused where to get my UserMeta

Yes, that maybe right but I would not like to break the API. Is it a big deal for your use case?

Yes, that maybe right but I would not like to break the API. Is it a big deal for your use case?

Yes, I use this subscribe API to implement "replication" feature. I need the UserMeta and the "bitDiscardEarlierVersions" of Meta.
Currently, I use my fork of badger in my project, it is doing well.

Do you mind explaining why you are using a fork? Is this PR the reason for it? Thank you patiently answering my questions.

Do you mind explaining why you are using a fork? Is this PR the reason for it? Thank you patiently answering my questions.

I want to implement a "Redis replication" like feature to the badger.
I am using "Backup" API to do a full synchronization when the mater/replica connected,
then I will broadcast the changes of master node keys to the replica nodes, so I am using the Subscribe API
to obtain the changes of master node.
At first I found the UserMeta of "*badger.KVList" in the Subscribe was missing, it will lost some data of my
master node.
And I also need to ignore the changes of some keys, I found the bitDiscardEarlierVersions of the key meta,
the Meta field of "*pb.KV" is begin with uppercase letter, so it could access outside the badger package.
I felt confused when I found the source code of Subscribe API, the UserMeta and Meta fields are both
begin with uppercase letter, I think the design of badger library is providing all informations of the k-v pair
to all the callers.